What is the reason of including the index map as part of the results?
There may be a software design reason I don't know, but from a conceptual point of view, the index map does not result from a participant executing the protocol (like the keys), and there is no concept of "voting" for the right index map. The index map is a public info that is fixed before the protocol starts, it is the same from the point of view of all nodes.
The DKG contract should already know the index map once the list of participating nodes is finalized (before DKG starts), and not rely on the nodes to vote for it.

I agree with your point about it not being necessary. The smart contract could construct the index map from the participant list, with implementation changes. It does not directly have this information, because nowhere in the smart contracts do we have the notion of canonical ordering of identities: we treat them as sets. There wasn't a motivation to change this - hence the inclusion of the index map in the result.

I understand the choice and had a look at onflow/flow-core-contracts#441 to understand the contract change. It would be good to clarify the implementation choice in the contract PR, since it may be confusing to see the indices as part of the result, and being voted for.

I also understand that the index map will only be available to the contract once enough honest participant voted for it as part of their submission. Is there an edge case of failure where the contract needs to access that map while not enough honest submissions have been gathered yet? just making sure there isn't such a case

Is there an edge case of failure where the contract needs to access that map while not enough honest submissions have been gathered yet?

We don't have such an edge case with the current implementation. The DKG contract in general has very little exposure to details of the DKG protocol. For example, whiteboard messages are opaque to the contract, and the contract's only interaction with result submissions (and by extension the index map) is equality comparison to evaluate whether two result submissions are the same.

What I meant is: the purpose of making the contract aware of the index map is to persist the index map, so that some nodes can query it if they don't have that context locally. But what if some nodes want to query that index map, and the contract doesn't know the map yet (because for some reason it didn't collect enough votes). That's the edge case I'm wondering about.
The information about the index map exists as soon as the beacon committee is finalized, but the contract only knows that information once DKG is over and it collected enough votes.

the purpose of making the contract aware of the index map is to persist the index map, so that some nodes can query it if they don't have that context locally

I would say that the purpose of making the contract aware of the index map is so that end result of the DKG process is informationally complete. In particular, it is useful for the EpochCommit to contain a full description of the DKG result (including the index mapping).

Node interactions with the DKG smart contract are limited to:

• read whiteboard messages
• write whiteboard messages
• write final result submissions

Nodes do not query the smart contract for the index map if they don't have that context locally. They only receive the DKG result via EpochCommit events, which are only produced after a DKG instance successfully completes.